Why is CI green when we have unused exports in the main branch, as per #462?

Hi @snitin315,

I'm not Joshua, but I found this comment in #462 😅

Unfortunately it can't detect this specific issue because types.ts is an entry point per package.json > "exports". From Knip's perspective, anything that is exported from an entry point is "used". Sent: #466.

Currently, since the types.d.ts file is exported via the exports field, I think Knip can't detect it as unused—it considers anything exported from an entry point as "used."

I’ll check back in once a decision has been made 😄

Generally I'm on the side of more tooling, I'd just like a better explanation of what prompted this PR and why the check is green if there are unused exports.

Hi everyone, it looks like we lost track of this pull request. Please review and see what the next steps are. This pull request will auto-close in 7 days without an update.

what prompted this PR

It's the two reasons noted in the OP:

• chore: Introduce Knip eslint#18005: Knip is a generally useful tool that finds unused code. I figured I'd add it in now while the repo is relative younger and doesn't have as much cruft built up.
• fix: remove unused types from types.ts #462: even though that specific classification of unused code can't be caught by Knip, the fact that there are things building up IMO is a signal that something like Knip would be useful

why the check is green if there are unused exports

It's #466 (comment) <- #462 (comment). The specific kind of issue in #462 -a type being exported out of the package but not used by any external consumers- is out of scope for Knip.

It seems that adding knip to the repositories is the approach the team wants to take.

Based on the references below, I'm marking this PR as accepted.

• Change Request: Add Knip to detect unused dependencies and exports js#695
• chore: add lint:unused script to run Knip rewrite#241

Hi, @JoshuaKGoldberg

When you have a moment, could you take a look at the merge conflicts and comments?